1. Field of the Invention
The present invention relates to remote monitoring of phone calls.
2. Description of the Related Art
Methods for managing incoming phone calls are known in the art.
For example, EP 1 435 722 relates to distributed communication services based on a presence technology platform. In particular, EP 1 435 722 discloses an implementation of a multiple appearance directory number (MADN) service where multiple telephone are rung, one is answered, the call is held, another telephone requests the cell, and the call is handed to the requesting telephone. The session initiation protocol (SIP) is used for the exchange of state information and the presentation of sessions or calls.
As stated by EP 1 435 722, in general, SIP is used to facilitate media sessions between any number of endpoints, which represent the devices communicating with each other, directly or indirectly via a SIP proxy. These endpoints may support any one or combination of data, audio, and voice media sessions, depending on the configuration of the respective endpoints.
A SIP endpoint is generally capable of running an application, which is generally referred to as a user agent (UA), and is capable of facilitating media sessions using SIP. User agents register their ability to establish sessions with a SIP proxy, such as a proxy server, by sending “REGISTER” messages to the SIP proxy. The REGISTER message informs the SIP proxy of the SIP universal resource locator (URL) that identifies the user agent to the SIP network. The REGISTER message also contains information about how to reach specific user agents over the SIP network, by providing the Internet Protocol (IP) address and port that the user agent will use for SIP sessions. A “SUBSCRIBE” message may be used to subscribe to an application or service provided by a SIP endpoint. Further, “NOTIFY” messages may be used to provide information between SIP endpoints in response to various actions or messages, including REGISTER and SUBSCRIBE messages.
When a user agent wants to establish a session with another user agent, the user agent initiating the session will send an INVITE message to the SIP proxy and specify the targeted user agent in the TO header of the INVITE message. Identification of the user agent takes the form of a SIP URL. In its simplest form, the URL is represented by a number or “<username>@<domain>. The SIP proxy will use the SIP URL in the TO header of the message to determine if the targeted user agent is registered with the SIP proxy. Generally, the user name is unique within the name space of the specified domain. If the targeted user agent has registered with the SIP proxy, the SIP proxy will forward the INVITE message directly to the targeted user agent. The targeted user agent will respond with a 200 OK message, and a session between the respective user agents will be established as per the message exchange required in the SIP specification. Media capabilities are passed between the two user agents of the respective endpoints as parameters embedded within the session setup messages, such as the INVITE, 200 OK, and acknowledgement (ACK) messages. The media capabilities are typically described using the Session Description Protocol (SDP). Once respective endpoints are in an active session with each other and have determined each other's capabilities, the specified media content may be exchanged during an appropriate media session.
In an example illustrated by EP 1 435 722, three endpoints are considered, which are telephones 1-3. Each participant device (telephones 1-3) is associated with a presentity, which watches all of its peers and informs all of its peers of significant service-related changes.
In this environment, initially, presentities P1, P2, and P3 associated with telephones 1-3, register the need to receive updates with each other. As such, presentity P1 for TELEPHONE 1 sends SUBSCRIBE messages to presentity P2 for TELEPHONE 2 and presentity P3 for TELEPHONE 3; presentity P2 for TELEPHONE 2 sends SUBSCRIBE messages to presentity P1 for TELEPHONE 1 and presentity P3 for TELEPHONE 3; and presentity P3 for TELEPHONE 3 sends SUBSCRIBE messages to presentity P2 for TELEPHONE 2 and presentity P1 for TELEPHONE 1 (steps 308 and 310). At this point, each presentity (P1-P3) for each telephone (1-3) is configured to notify the others of changes in state. Each of the telephones 1-3 is configured to simultaneously ring in response to an incoming call to a defined directory number or address. A proxy server recognizes an incoming call to telephones 1-3 and sends an INVITE message to each of the telephones 1-3 to initiate a media session. Any of the INVITE messages may be responded to with a 200 OK message.
In the example, TELEPHONE 2 is answered. As such, TELEPHONE 2 sends an OK message in response to the INVITE message to the proxy server 24, and presentity P2 sends NOTIFY messages to presentities P3 and P1 indicating that it was answered. Then, it is assumed that after establishment of a media session with TELEPHONE 2, the media session is placed on hold by the user of TELEPHONE 2. In response, TELEPHONE 2 sends an INVITE message placing the call on hold to the proxy server 24, which forwards the hold message on to the device originating the media session in a direct or indirect fashion. Presentity P2 then sends NOTIFY messages to presentities P1 and P3 indicating that TELEPHONE 2 has placed the media session on hold.
Assuming that the held session is taken over by TELEPHONE 3 in response to a call request, presentity P3 sends a NOTIFY message including a request to take over the call to presentity P2 and send a NOTIFY message indicating the same to presentity P1. In response, TELEPHONE 2 refers the session to TELEPHONE 3 by sending a REFER message to the originator of the call via the proxy server 24, whereupon the originator of the call will respond by sending an INVITE message configured to establish the media session with TELEPHONE 3 via the proxy server 24. Presentity P3 will then notify presentities P1 and P2 of the state change.
The Applicant notes that according to the above distributed service, each participating device has to subscribe to notification services for all the participating devices of interest. In particular, each participating device has to send a SUBSCRIBE message (and subsequently a NOTIFY message) to all the participating devices of its interest. This implies that a high number (n*(n−1)) of SUBSCRIBE (and subsequent NOTIFY) messages are exchanged among the n participating devices interacting with each other. Thus, the number of exchanged messages quadratically increases as the number n of participating devices increases.
Moreover, the Applicant notes that in the service disclosed by EP 1 435 722 each of a group of telephones is configured to simultaneously ring in response to an incoming call to a defined directory number or address. A proxy server recognizes an incoming call to the group of telephones and sends an INVITE message to each of the group of telephones to initiate a media session. This implies that, when the telephones of the group belong to different users (for example, in an office situation), a user wishing to call any of said users has the possibility to call all of them at once, by making only one phone call to the directory number or address of the group. However, the service disclosed by EP 1 435 722 is not practical when the group of telephones is associated with a same USER-A so that all of the telephones of the group of USER-A simultaneously ring in response to an incoming phone call to the directory number or address of the group. In fact, according to this service, USER-A is required to spread, besides the phone number of each telephone, an additional number (i.e., the directory number or address of the group) to all the acquaintances of his interest. Moreover, USER-B, wishing to call USER-A, is required to know and note down, besides the phone number of each telephone of USER-A, also the directory number or address of the group associated with USER-A, and to remember, at the time of making the phone call, to dial the group of USER-A and not a specific telephone thereof. Therefore, the good functioning of the service is in the user's hands.
WO 2005/109844 relates to call pick up group (CPG) functionality which enables a user in a CPG to answer a phone call received at a phone number of the CPG that is different from a phone number of that user.
In particular, WO 2005/109844 discloses a communication network comprising a plurality of endpoints and a call control unit. When an incoming phone call is presented to a CPG for pickup, the call control unit is adapted to access call data associated with the CPG and communicate that data to one or more users in the CPG. Call data associated with a CPG may include data identifying one or more users in the CPG, data indicating whether one or more users in the CPG are available, data indicating a current presence status of each one or more users in the CPG, data indicating a current call status of each of one or more users in the CPG, data indicating a willingness of each of one or more users in the CPG to pick up an incoming phone call, other data, or a combination of such data.
In particular embodiments, when communication network receives an incoming phone call to a phone number corresponding to a CPG, communication network identifies one or more endpoints that one or more users in the CPG are currently present at. Communication network then routes the incoming phone call to endpoints to present the incoming phone call to those users for pickup. Any one of those users may then pick up the incoming phone call.
In particular embodiments, according to CPG functionality, when communication network receives an incoming phone call to a phone number corresponding to a CPG, communication network does not present the incoming phone call to all users in the CPG for pickup, but may nonetheless communicate data to all users in the CPG. For example, when an incoming phone call is presented to a CPG for pickup, call control unit may access call data indicating a current call status of each user in the CPG and communicate that data to one or more users in the CPG for display. That data may inform a user in the CPG who is considering whether to pick up the incoming phone call how many other users in the CPG are currently on other phone calls. That data may also inform a user in the CPG who is considering whether to pick up the incoming phone call how many other users in the CPG are not currently on other phone calls and are therefore available to pick up the incoming phone call. If no other users in the CPG are available to pick up the incoming phone call, the user in the CPG who is considering whether to pick up the incoming phone call may pick up the incoming phone call in response to no other users in the CPG being available to pick up the incoming phone call.
Applicant notes that in the service disclosed by WO 2005/109844, the communication network receives an incoming phone call to a phone number corresponding to a CPG and then routes the incoming phone call to all or some of the endpoints associated with said CPG. Analogously to EP 1 435 722, this implies that when the endpoints of the CPG belong to different users (as shown in FIG. 2 of WO 2005/109844), a user wishing to call any of said users has the possibility to call all of them at once, by making only one phone call to the number of the group. However, the service disclosed by WO 2005/109844 is not practical when CPG is associated with a same USER-A so that all of the endpoints of the group of USER-A simultaneously ring in response to an incoming phone call to the number of the group. In fact, according to this service, USER-A is required to spread, besides the phone number of each endpoint, an additional number (i.e., the number of the group) to all the acquaintances of his interest. Moreover, USER-B, wishing to call USER-A, is required to know and note down, besides the number of each telephone of USER-A, also the number of the CPG associated with USER-A, and to remember, at the time of making the phone call, to dial the group of USER-A and not a specific endpoint thereof. Therefore, the good functioning of the service is in the user's hands.
Draft-mahy-sip-remote-cc-02.txt, SIP WG; Internet-Draft; R. Mahy (SIP Edge LLC) and C. Jennings (Cisco Systems), Oct. 23, 2005; relates to “Remote Call Control in SIP using the REFER method and the session-oriented dialog package”.
As stated in this draft, while the SIP core protocol describes how user agents originate and terminate sessions, remote call control is the manipulation of conversation, dialogs, or sessions. This manipulation involves sending REFER requests to a user agent (UA) which is directly involved, using information obtained via the dialog package. The REFER method is used to implement call transfer and, in general, to ask another UA to do something on your behalf. For example, using remote control, a computer or organizer could cause a nearby phone to dial from numbers or URIs in a document, email, or address book; allow users to answer or deflect incoming calls without removing hands from the computer keyboard; place calls on hold; and join other sessions on the phone or otherwise.
In the example on page 5 of this draft, in the requests labeled with 1 and 2, Alice's PC or PDA sets up a subscription to the dialog package from Alice's phone. All of the subsequent NOTIFY messages are notifications about changes in the dialog state at Alice's phone. Message 8 is an invitation received by Alice's phone from Cathy. With REFER messages 9, 10, and 11 Alice's PC or PDA would cause Alice's phone to redirect, reject, or accept the invitation.
The Applicant notes that according to the remote call control disclosed by this draft, each Refer-Issuer (the user agent issuing the REFER request) has to set up a subscription to the dialog package from all the REFER-Recipients (user agents receiving the REFER request) of its interest. In particular, each Refer-Issuer has to send a SUBSCRIBE message to each REFER-Recipient of its interest, in order to be enabled to manipulate it. This implies a high number (n*(n−1) of sent SUBSCRIBE messages when the number n of devices involved is high.
Moreover, the Applicant notes that, in the remote call control disclosed by this draft, any Refer-Issuer device, unless a proper authorization policy is provided, can set up a subscription with a REFER-Recipient to manipulate it. Thus, in order to avoid fraudulent manipulations, each REFER-Recipient should be suitably configured in order to be enabled to accept SUBSCRIBE messages only from predetermined “authorized” Refer-Issuer device(s). However, this would require the user to take upon himself the burden of configuring each REFER-Recipient device and keeping said configuration updated. Moreover, it would require high performance REFER-Recipient devices, capable to act as server devices to manage incoming SUBSCRIBE requests by REFER-Recipient devices and to authorize only the authorized Refer-Issuer device(s). The workload required to these REFER-Recipient devices increases as the number of SUBSCRIBE messages to be handled increases.
Furthermore, in the remote call control disclosed by this draft, the user devices are enabled to exploit communication network resources without giving any possibility to the communication network to control it. This may be disadvantageous in term of reliability and fraud issues.
The Applicant faced the technical problem of providing a method for managing incoming phone calls which allows overcoming the above mentioned disadvantages of the prior art.